Welcome @anshuman-agarwala!

It looks like this is your first PR to kubernetes-sigs/kubebuilder 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubebuilder has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @anshuman-agarwala. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Hi @anshuman-agarwala

Thank you a lot 🎉
In this case, we are changing the e2e tests of the projects, which are scaffolded for end users
So, the emoji 🌱 cannot be used, since it is for changes that does not impact the end users
I update the title since we use it for our release notes I hope that you do not mind.

Hi @anshuman-agarwala

Thank you a lot 🎉 In this case, we are changing the e2e tests of the projects, which are scaffolded for end users So, the emoji 🌱 cannot be used, since it is for changes that does not impact the end users I update the title since we use it for our release notes I hope that you do not mind.

No Problems!
I see that e2e test is failing, the logs are as follows

running: make deploy IMG=example.com/project:v0.0.1
  [FAILED] in [BeforeAll] - /home/runner/work/kubebuilder/kubebuilder/docs/book/src/multiversion-tutorial/testdata/project/test/e2e/e2e_test.go:71

Could you help me with how I can fix this?

Hi @anshuman-agarwala,

The tutorials in the documentation are built from the sample projects under book/../testdata, such as:
🔗 https://github.com/kubernetes-sigs/kubebuilder/tree/master/docs/book/src/multiversion-tutorial/testdata/project

To ensure consistency, we update these samples based on PR changes and verify them using e2e tests. The additional code and modifications on top of the scaffolded content are implemented in:
🔗 https://github.com/kubernetes-sigs/kubebuilder/tree/master/hack/docs

The Issue:

The error occurs because Prometheus integration is enabled in the Kustomize files, but Prometheus itself is not installed.

Possible Solutions:

✅ Option A:
Update hack/docs to ensure that the removed code from the default scaffold is explicitly added to the sample used in the Multiversion Tutorial. This means adding the necessary code under:
🔗 https://github.com/kubernetes-sigs/kubebuilder/tree/master/hack/docs/internal/multiversion-tutorial

With this approach, when we run make generate-docs (triggered by make generate), we will maintain the current e2e tests at:
🔗 https://github.com/kubernetes-sigs/kubebuilder/tree/master/docs/book/src/multiversion-tutorial/testdata/project/test/e2e

✅ Option B:
Modify the code so that it no longer uncomments the Kustomize files to enable Prometheus by default.

Personally, Option A seems preferable since it keeps this scenario as a documented example for end users.

WDYT? 🚀

Hi @camilamacedo86
Option A sounds good but I looked at the other E2E book samples runs, they have failed in the same way, is it due to the same problem? In that case we may need to look at Option B, right?

Hi @anshuman-agarwala,

Option A sounds good, but I noticed that other E2E book sample runs have failed in the same way. Could this be due to the same underlying issue? If so, should we consider Option B instead?

Good catch! 🥇

Getting Started Sample

For the getting-started sample, we should not simply uncomment the line in the kustomization.yaml file to enable the integration with prometheus:
🔗 kustomization.yaml#L26-L27

Why?

• This is a basic example, and we don’t need to extend it further.

How?

• We should delete the following function call instead:
  🔗 generate_getting_started.go#L52-L57

CronJob and MultiVersion Samples

The CronJob and MultiVersion samples share a similar generation process. The MultiVersion sample builds on the CronJob implementation. See in the hack/docs that we re-use it.

So, to add E2E test we can:

• Modify the CronJob generation script:
  🔗 generate_cronjob.go#L85-L127
• Introduce a new function that injects E2E test code.
  • Similar to this function:
    🔗 generate_cronjob.go#L629-L642
  • This function should find and replace content in the tests/e2e path.

Where?

We should create a new file to store constants for e2e_implementation.go under:
🔗 cronjob-tutorial directory
(similar to the existing structure).

In this way, we cover more cases in the tests and provide more examples for end users. WDYT?

HI @anshuman-agarwala

Great work 🥇
It seems missing only a nit for we are able to get this one merged.
See the lint issues. You can run make lint locally to check them out.
Can you please send a fix?

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anshuman-agarwala, camilamacedo86

The full list of commands accepted by this bot can be found here.

The pull request process is described here